Field of the Invention
This disclosure relates generally to load balancing among servers. More particularly but not exclusively, the present disclosure relates to providing network components with capability to detect mapping between public and private addresses and to provide the public addresses for use in load balancing.
Description of the Related Art
Under the Transmission Control Protocol/Internet Protocol (TCP/IP), when a client provides a symbolic name (a Uniform Resource Locator or URL) to request access to an application program or another type of resource, the host name portion of the URL needs to be resolved into an IP address of a server for that application program or resource. For example, the URL (e.g., http colon double-slash dub-dub-dub dot foundrynet dotcom slash index dot htm) includes a host name portion dub-dub-dub dot foundrynet dotcom that needs to be resolved into an IP address. The host name portion is first provided by the client to a local name resolver, which then queries a local Domain Name System (DNS) server to obtain a corresponding IP address. If a corresponding IP address is not locally cached at the time of the query, or if the time-to-live (TTL) of a corresponding IP address cached locally has expired, the DNS server then acts as a resolver and dispatches a recursive query to another DNS server. This process is repeated until an authoritative DNS server for the domain (e.g., foundrynet dotcom, in this example) is reached. The authoritative DNS server returns one or more IP addresses, each corresponding to an address at which a server hosting the application (“host server”) under the host name can be reached. These IP addresses are propagated back via the local DNS server to the original resolver. The application at the client then uses one of the IP addresses to establish a TCP connection with the corresponding host server. Each DNS server caches the list of IP addresses received from the authoritative DNS server for responding to future queries regarding the same host name, until the TTL of the IP addresses expires.
To provide some load sharing among the host servers, global server load balancing GSLB) switches are sometimes used as proxies for authoritative DNS servers, together with one or more site switches each associated with one or more host servers. Each site switch provides the GSLB switch with current site-specific information (“metrics”) regarding access conditions to the host servers associated with the site switches. The GSLB switch then processes the addresses returned by the DNS server using the metrics compiled from the site switches and provides an ordered address list having the optimum address for access listed at the top. An example of a GSLB system and description of associated metrics are disclosed in U.S. application Ser. No. 10/376,903, entitled “GLOBAL SERVER LOAD BALANCING,” filed Feb. 28, 2003, assigned to the same assignee as the present application, and which is incorporated herein by reference in its entirety.
An increasingly common feature of networks with internal and external connections is the mapping of private (internal) server addresses to public (external) addresses via a mapping device, such a firewall or Network Address Translation (NAT) device. Another frequent characteristic of such networks is the use of virtual IP addresses (VIPs) in addition to real server addresses. A VIP can have either or both a private address and a public address. The authoritative DNS server for which a GSLB switch is being used as a proxy for the specified domains is typically configured with the public addresses for these domains, so that the GSLB switch can reorder these public addresses returned in the authoritative DNS server reply as part of the GSLB algorithm when a client requests access to any of the specified domains. In addition to having a GSLB switch communicate directly with site switches to obtain metrics information from the site switches, the GSLB switch also receives from the site switches a list of VIPs configured on the site switches. If these VIPs are private IP addresses mapped to public IP addresses by a device such as a firewall or NAT device, then the site switch is unaware of the mapping and only communicates the private VIP addresses to the GSLB switch. However, since the authoritative DNS server is configured with the public addresses rather than with the private addresses, the public VIP addresses received in the DNS reply do not match the private VIP address on the GSLB switch and are treated as real addresses by the GSLB switch rather than as virtual addresses. Since most of the metrics are applicable only to virtual addresses and not to real addresses, the GSLB switch cannot apply many of the metrics to the received private address, thereby reducing the overall efficiency or accuracy of the load balancing system.
As a further elaboration, a VIP having a private IP address is configured on a site switch. The site switch would know the private IP address associated with that VIP, but would not know the public IP address mapped to that private IP address by a mapping device (such as a firewall device). As a result, the site switch would communicate only the private IP address (and its associated metrics information) rather than the public IP address to the peer GSLB switch. Meanwhile, the authoritative DNS server (for which the peer GSLB switch is serving as a proxy and for which the GSLB switch is handling load balancing for the site having the VIP) has been configured with only the public IP address for the VIP for that site. Accordingly, when the GSLB switch receives the DNS reply from the authoritative DNS server, the GSLB switch would not recognize the public IP address in the DNS reply as being a VIP at that site, since the GSLB switch is only aware of the private IP address of the VIP received from the site switch. The GSLB switch therefore treats the received public IP address as a real address, since the private IP address is different from the public IP address in the DNS reply being reordered by the GSLB switch. Accordingly, the GSLB switch would not apply (or would incorrectly apply) some of the metrics, such as the active bindings metric (where the best IP address is the VIP that has the maximum number of active real servers bound to it), which are usable only with virtual addresses. Had the GSLB switch been able to correctly identify the received address as being a VIP, the GSLB would have been able to apply the correct metric(s) for VIPs when reordering the reply from the authoritative DNS server for which it is serving as a proxy.